Release 10.1A: OpenEdge Application Server:
Developing AppServer Applications

Deciding on the scope of individual requests

When designing an application service, the scope (or power) of each remote operation ultimately depends on the transaction requirements of the application. However in general, it is a good practice to make operation requests as powerful as possible in order to hide the details of the AppServer 4GL from the client programmer. Also, the more power that remote operations have, the fewer requests must be made from the client to accomplish tasks over the network, thus reducing the opportunity for the network to be a bottleneck.

Session-managed operations

For session-managed applications, which support complex transactions, the operations can perform simple (less powerful), fine-grained procedures and functions because the ultimate result for a client does not have to be completed in a single request. Each procedure or function executed in a series of session-managed requests can help to assemble the context of a single transaction until a single committing operation completes the transaction after this context is complete. An example might be a transaction to assemble a bill of materials (BOM), where the transaction depends on what components are already in stock for the BOM, requiring the client to invoke different operations to complete the structure of the transaction. Once the structure is completed for any missing components, the BOM transaction can be committed using a final operation.

Session-free operations

For a session-free application, whether simple or complex (powerful), each operation must complete any transaction that it starts. Operations typical of this type of application include returning the current outdoor temperature given a zip code, or returning a zip code given a street address. A more powerful example might be an operation that returns all the available seats on airline flights to a given destination, followed by another operation that attempts to reserve a selected list of seats on any of the available carriers, based on a set of parameterized preferences, or specifically by seat number. In all cases, these operations complete their function in one request, and if a result is in some way unsuccessful, the request might simply be repeated with or without modification of the parameters involved.

Context can, however, be maintained for a session-free application if the client maintains the context between requests using input-output parameters provided by the application service procedures or Web service operations. An example might be an order entry Web service that allows a user to obtain status of a particular order, then examine the detail lines of that order.

In this case the context might be a customer number passed in a getOrders procedure to get the status of all that customer’s orders. This might be followed by a getOrderLines procedure for a selected order, with both the customer number and order number passed as parameters to get the detail lines of a selected order for the customer. In this case, the context is really being maintained in persistent storage, such as a database, that is shared by all clients of the application.